-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slight refactor to collection widening #30076
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might need an explicit inline annotation, since part of the existing trick is that this elides dispatch by moving all of the dynamic cost into one branch
Ok |
Wait, I'm confused.... adding the |
IIRC, |
Oh ok |
Well it looks like this is passing. Is it worth running benchmarks? |
I like this. I hope this pattern will be easier to replicate in custom array code and custom operations on containers. Currently I find implementing a “widening” approach instead of a “inference” approach to container allocation quite tiresome, but I think this could help immensely. |
Ok I think I've addressed all the comments |
Good? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks both sound and useful.
Is this backsportable? |
No, its not a bugfix. |
Pull out specifically collection widening to its own functions. This will allow overloading these functions for data-structures which are easier to widen than Arrays, e.g. ModelArrays (see #13942)
The eltype checks seem redundant but help make the functions more generalizable. I think they're costless anyway.